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The development of a mathematical model of the 
Illinois Library and Information Network (ILLINET) is described. 
Based on queueing network theory^ the model predicts the probability 
of a request being satisfied, the average time from the initiation of 
a request to the receipt of the desired resources the costs^ and th6 
processing loads. Osing a hypothetical network, two sets of operating 
policies are analyzed: those emphasizing minimum delay and those that 
maximize the probability of successfully meeting user requests. Cost 
constraints and value judgements about tradeoffs between delays and 
the probability of satisfying user requests are considered in the 
context of network operating policies. The impact of union listings 
of holdings, automated circulation at the individual libraries, and 
computer-controlled networks is analyzed. Future plans for network 
modeling together with the equations used in the network simulation 
are also presented. (DGC) 
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1. l.'.'.'KOi.Ut • 'Oy .) hiv.v.i;Y ■' 

'i'h d }.(.:!jo;.t; sii. r.arL/.es i)ro.;i-esi on Lhvi (.'ovc !.)jVK>i:l of a 
inat.iK.vut-Lcc-1 :uvtiel of vhe Illinois library a-ul InJ.orr.atiun ICcM.-oik. The 
nu'iin objf-ctiv. of il.i, project in to produce, a r,.n;.heuatical mod^l and 
associated co.:.,,iir..r pro:;rar,>s tor u^^c^ by the State Library in evaJuation 
and p33r,niiv. of the Illinois network, '..'hile this goal is rather ..peclfic, 
we are endcavorJng to develop a underst-dir.g of library n.:i:uorkis 

and a general ...odeJ o£ their operation. With this point in mind, much of our 
reseorch ha.^ been directed at broad issues that have meaning for n-ost library 



networks. 



In Section II, wo discuss the ILLIKET modei in general qualitative 
term? of resources, demands, and network operating policies. The model is 
basically a queueing network which predicts probability of a request being 
_ satisfied, average time from initiation of a request to receipt of the 
desired.. resouixe, costs, and processing loads. 

Using a hypothetical network, we consider two fairly general classes 
of network operating policies; those that emphasize minimization of delay and 
those that emphasize maximization of probability of success. With the II,LlN!iT 
model, we show how network dispersion and the distribution of resources 
affects the appropriateness of these two classes of policies. Combining 
cost constraints and value judgements cojicerning the tradeoff between average 
delay and probability of successfully satisfying a request, we briefly dis- 
cuss choosing a specific network operating policy. 

V7e consider how network performance (probability of success, 
average delay, and co.-its) is affected by union listings of holdings, auto- 
mated circulatipn at the individual resource libraries, and a computer- 
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controlled network. Based on the cost reimbursement procedure in Illinois, 
union listings appear to have significant economic benefit not to mention 
the improved service possible with such listings. 

The effect of processing load on average delay via queueing is 
considered and sho^^n to have the potential of substantially increasing proc- 
essing times throughout the network. This increase either costs the requestor 
in terms of delay or costs the network in terms of increased staffing and/or 
productivity to maintain acceptable levels o£ service. 

Section III discusses the future plans of our project which include 
analysis of the Illinois network in light of the data currently being gathered 
and the impact of possible applications of computer and communication technology. 

In Appendix A, the equations currently incorporated in the ILLIl^ET 
model are derived. Appendix B includes a summary of the ILLINET User's 



Manual. 

In this report, we have performed a rather detailed analysis of a 
hypothetical networking situation. This was partially motivated by the lack 
of recent data from the Illinois network. However, the main reason for 
considering a hypothetical network was to clearly illustrate the numerous 
policy issues and how various network parameters might affect the resolution 
of these issues. ~ 
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li. roi.iu? -i.s:,.s AX,-) Tui: a;;alysis of a iiYruui-; i ical ::!;t'.sO!,k 

A. InLrcHlufi, Lo'i 

rur 1^..sL ))rojccu rrport, i.ho. ilLJVcT r.,oclo2 Ivs h«en 
considot.Voly r>.vi:;,d aru-i oKt.nuod. If t,ow xucorporates a cii»tribur.c-d 
queueing ncfvurk th.at allovj; for consic'cracion of a rather robust sut of 
network oporatii-j. poJIcioc;. Xo faci] i.tate upg of ILLl.^ET as an rauilysis and 
destcn tuol, the .LntcracLive features of the computar program have boon 
considerably (;nh;.nced. 

In this section of this report, we want to discuss how ILLIKET 
can be used to analyze a library/information network. We will stress inter- 
pretation of model output and discussion of policy issues. The reader 
interested in detailed assumptions and procedures is referred to the 
Appendices . 

B. The Model 

We start with a set of geographically disperse resources and a 
set of geographically disperse demands. Our goal is to match demands and 
resources so as to maximize probability of satisfaction (fill rate), mini- 
ini;:e average delay in receiving the desired resource, and minimize the cost 
of providing the service. Combining resources, demands, and a communication 
protocol, we have a network. We will assume that the characteristics of the 
resources and demands are relatively static. This leaves the communication 
protocol or what ^.e term the network operating policy as the means to achieve 
the goals noted above. 

ILLINET is a model that predicts the effects of network operating 
policy on fill rate, average delay, cost, and processing loads. In essence, 
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the r-ouc I if. a hi Ovcucl) ^ c .'il q.u'v-iny. . '\'ork. IL :s ji iorarch ! cai in ih>? ^^o.nuo 
thai different portions of Lho i>:-fvork < n Le d-rined to have differrnl levels 
of r^sponsiSiJir' . QiuuuJng copio*; ?:'.t:o play vhen \;g 1o\; Ihe proco-siup^^ tirjo 
at a point in the riCtwork to be a function of the danand oa that point. 

To be consistent uilh the tcrninojogy used in the Illinois ni^tvork, 
the resource points in tho netv.ork V7i]3 he called Centers. The points fron 
which denand cn\'3nat(\<^ will be railed Syj;ite:ns , -* Demand can be catc.g^^-'-izcd 
according lo subject area. We v:ill refer to subject areas as classes. 

C. Network Opera tins Policies 

By network operating policy, v;e mean the prearraitged paths of 
requests through the network. Upon sending a request to a Center, three 
things may happen. First, it may be satisfied and the desired resource 
delivered to the requestor. If the request is not satisfied at the initial 
Center, it may be forwarded to another Center. It is also possible that an 
unsatisfied request is not forwarded, but is categorized as unfillable and 
returned to the requestor. 

For a given class of requests from a given System, the network 
operating policy specifies the Center at which the request is initiated into 
the Center level of the network and the subsequent routing of the request 
should it fail to be satisfied at that initial Center. The specification 
of the Center at which the request is initiated we have chosen to term 
allocation . The choice of the path by which a request proceeds through the 

In Illinois, Systems are the points at v;hich the requests from local 
libraries are aggregated for transmission to the Centers. 
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noiv;ovk sv rm cou! »r > . Kiu n vt-r r.>-|uf'ol >s s irir>r • f^c! ^ itf^ path leiran-IXM 

and <!u* s not c.oiuinik. to fol3<n% the tj[;ccif roulipj, T!iuh> a icquoat dcoc! 

not always proct at every Center spcciiied in -its route. 

Cla?s i roqucrfts that eiittr the urtv;ork at Center i are termed type 

ij requewt.*-;* A^rociatcd uitii typo ij requests is a routing vector r xiho^vo 

1 j k 

k refers to the k ' Center to which a type ij request is routed if it has not 
yet been satisfied. The ienj^tii of the routing vector (the uiaximum I's n ' 
\vhich may take on valuo^^ of i, 2, N where N as the nurber of Centers in 

the netv/ork. The process by which a request proceeds along the route 
specified by its routing vector is termed referral. 

To decide on the routing of a request one must choose r and n 
One has N choices for the first Center at which a request will be processed • 
One has N - 1 choices for the second Center, N - 2 choices for the third Center^ 
etc. Since we might choose values of n^^ .ranging from 1 to N, we find that the 
^tal number of possible routing vectors for a type ij reques.t is given by 

N 

I m 

i=l (K-i)! 

For example, if N = 4, the total number of possible routing vectors is 64 
while N = 10 yields a total number of 9,864,000. 

The above results could be applied to each class of requests from 
each System. If there are L Systems and M classes, then there would be a 
total of 

N 

1=1 (K-i)! 
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ConleV:j, Uit-ru arc 8>U'2 i^o^.ilhl^* netv.o/k oparctinn policies. Thi5; jjivcn 
the LVacor an Jdt-: of ihv compjor i.iy of tho prof lo'n of c-hoo:r:ir.a a pol'Ic, . 

However, need not .'^ruH.if Icai J> conniocr such a rolni^t: set of 
policies to pursuo Koma of the oc^peivJ policy isr^uos* Inhtc d, \;o v;ill con- 
sider two clas;^. ? of poHr.i3G anJ hov each miaht be pproprialo xu different 
situations. 

Before we define these policies, coi-ii Ider so;.ie of the basic trade- 
offs invoived in choosinii a policy. To n^axiniixe probability of successfully 
satisfying a rc-quest, the request dhould be sent to the Center most likely to 
fill a request In that class. To minimise dalay in satisfying a request, the 
request siiouJd be sent to the Center least distant (in delivery time) from the 
requestor.-^ However, more often than not, the Center with the greatest 
strength in a given resource class \;ill not be the Center least distant from 
the requestor. Thus, we have to trade off delay versus fill rate. In other 
words, how many additional requests would have to be satisfied to justify 
a given increase in average delay to all satisfied requestors? 

One approach to resolving chis issue is to initially send requests 
. to the least distant Center and then route those not satisfied to the Center 
with the most strength in the desired resource class. The result is that some 
requestors receive relatively fast service, but the remaining requestors 
(those not satisfied at the least distant Center) wait longer than they would 
have if their requests had been initially sent to the Center with the most 
strength in the resource class. Whether or not this policy is acceptable ■ 



*We are, for the moment, assuming that all Centers have approximately equal 
processing times. 
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du> Uis:Hr;.joM the i: f.vr!:. ; nclv:,r!: .^it;) 3^;: ilj-,*v r.^j.^ th^ 

rina^ly, it (li'i.vr<l-; f»-» bu:l<»( l avrj;!jhli> rfi.icc rerin--ts sati:.."*c<l r.i the 
rearoi,l Cop.tcr anJ L'lcn routCwi to tho. ytron^.u^t Center wj]l incu>: p-ocorr>irg 
coiiLs at :u>t:h Center.*^, 

Ucfcrrais not cnly result in increa^tnl total proccs^^ina cosr.-.. 'U)cy 
also rri5u]t in a higher i)roCi\-.i:inf, ]oad on the network. If ti.e stafn.ig oi 
the network is- not incrcnsoil, then increased proccs.sins load will result in 
increased procorsins time (because of queueing), Thmj, to keep proccssjn?, tina^ 
x^ithin accoptahlo lin"^t«, additional staff and/or new Cochnolusy is necessary. 
Whether or not this is feasible depends on whether or not the increased funds 
generated by the additional processing load arc sufficient to cover such 
iiivestment. 

There are also other investment issues. VJould a union list of the 
notu'ork's holdin^;s bo a reasonable investment? Wo wil] shou later how such a 
list could result in substantial savings in network operating costs. Khnt 
are the effects on network perfornance of automated circulation systems at 
the Centers? Such systems would decrease processing time but, depending on 
the reimbursenent policy, may have little effect on network operating costs. 
Would computerized allocation and routing of requests bo of value? It 
certainly would rake service more consistent and, if it could access a union 
list of network holdings and automated circulation systems at the Centers, 
could result in an almost instantaneous response to the requestor concerning 
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whctiK^r ox- not his rcqiiei>L will be s^ntisf ic.d. liowt-voi j it von.ul roI. i^iatrvialJv 
aiftict proces.s jii^; cine- at i:.e Center rhere the request was salLsfied or 
delivery ti^e Cor the desired r^^^oin-ce. The hasJc savings would be tho tima 
and cost of referral. 

Tiie overall policy issues hin^e on the tradeoffs bet\;een service 
and cost and betvjeen the tvjo measures of service (fill rate and average delay). 
In the next section of this report, \;e V7i]i quantitativejy consider those 
tradeoffs by analyzing a hypotheticaL network. We will consider policies that 
attempt to inininizf. delivery time (termed '^tinie" policies) and poi5.cies that 
try to maximize fill rate (termed "strength" policies). Also, xie. will look 
at the effects of referral on all three measures of performance. 

D, A Hypothetical Network 
♦ 

We have tv;o motivations for considering a hypothetical network 
instead of an actual network. Our first reason is that there is not yet 
sufficient and consistent data for the Illinois network to allow a rigorous 
analysis. This condition will be remedied in the next fev7 months and a 
detailed analysis of the Illinois network will be the subject of our next 
project report. The second reason for considering a hypothetical network 
is that we can construct a network situation that will clearly illustrate 
the important policy issues and avoid the obscurity brought on by statistical 
effects and policy irregularities. 



*It would not yield improvement in processing time beyond that resulting 
from a union list and automated circulation. 
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A "map" of our hypoubei-ical naiv.ork is shown in Figure There 
are four resource Centers- and sixt:c<.n Systoi^ whore vequoazc from local 
libraries are as^rosated f.r t:rau....issi.on to the Centers. The scale of our 
map is in delivery tlir.o units. We a.siV.e that the four Centers are on the 
corners of a square. The squ.re has dimensions of I) delivery time units on 
a side and D delivery tln^e units across its diagonals. The di5:tance 
between each System and the closest Center is one delivery time unit. 

D is our measure of the dispersion of the network. D nay be 
proportional to distance if the mode of delivery consumes time in proportion 
to distance. Hou-ever. the relationship between distance and time is not " 
■always as simple as one ndght suppose. For example, .,ail traveling within a 
city may take longer to reach its destination than mail traveling coast-to- 
coast. Ho;.ever, the point of this discussion is to note the effects of D and 
not to consider hov; D might be measured. 

We next want to consider the distribution of resources in the net- 
work. For convenience, we will assume that there are eight subject areas or 
classes and that the i*^^^ Center will satisfy a class 3 request with probability 
p.j. We will consider two resource distributions: uniform and skew. A 
unifonr. distribution is such that all four Centers have equal values of p 

ij 

A skew distribution is such that one Center has a high value of p while 
the other three Centers have low and equal values of p . . . We will refer to 
the high value of p as the "strong" fill rate and to the low value of p 

ij 

as the "weak" fill rate. 



n^r'^'^'i"!? °^ hypothetical network and the data values assumed 

are not meant to reflect the specific operation of the Illinois network. 
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C = Center 
S = System 

Scale =^ Delivery Time Units 



A Hypothetical Network 



Figure 1 
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\sith a imiforni resource distribution, cssunc that all Contors 
have strong flJl rates in all classes. With a ske.: resource distribution, u 
assume that ContLr 1 is strong in cla$;£>es 1 and 2 v.hJle being weak in cl;is5?e 
3 through &; CcvXov 2 is stror.g in clasi>es 3 and 4 while being weak in the 
other clcisses; etc. 

We will assuiije that each System receives and transmits an average 
of 1,000 requests per year in each class. With sixteen Systems and eight 
classes, this results in a total of 128,000 requests per year. 

If a request enters a Center v/ithout a call number, it is 
"searched" to see if the Center owns the desired item. We will assume that 
the cost and/or reimbursement for a search is $1,00, If a request is filled 
we will assume the cost and/or reimbursement to be $2.00 • 

In Appendix A, we discuss how each Center is composed of six 
processes: in-process request, search, verify, obtain, out-process item, 
and foncard request. Initially, we have assumed that these processes 
consume an average of 0.125, 0.500, 0.500, 0.500, 0.500, and 0.125 time 
units respectively. Later in this report, we will consider the effects 
of processing time being a function of demand. 

We have now completely defined our hypothetical network. Its 
symmetry and regularity are highly idealized. The advantage of this 

idealization is that we now can consider the effects of network structure 

k 

and policies unencumbered by the differences in demand and policies among 
the various Centers and Systems. 
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E. Analysis and Results 

Before discussing oux* analysis, let us suiv.marize the variables we 
are considering, 

1. Allocation policies: time and strength 

2. Routing: n. ,=1,2,3,4 

3. Dispersion: D = 3, 6, 9 

4. Resource distribution: uniform and skew 

5. Strong/weak fill rates: 0.5/0.3, 0.7/0.1 

We are assuming a fixed average demand of 128,000 requests per year and 
search/fill ^reimbursement costs of $1.00/2.00. 

For our first analysis, we assumed that all requests enter the 
network without call numbers and that the only reason requests are not 
filled is because the desired resource is not o\med. Further, we assumed 
the processing time is net affected by the level of demand (i.e., no queueing) . 
We will relax these assumptions and discuss them in more detail in later 
analyses. 

Tables I through IV are compilations of the output of ILLINET 
for the assorted combinations of the variables nojted above. It should be 
stressed at this point that the specifics of the hypothetical network or, 
for that matter, the specifics of the Illinois network are defined by the 
input data for the ILLINET model and are not "hard wired" into the program. 
Thus, analysis of different networks is accomplished by changing the data 
and not the program. 
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The performance measures in TahJes 1 and 11 are total natisfied, 
total cost, luvit cost, and marginal unit cost* Since the total input to 
the network is 128,000 requests per year, the total satisfied divided^ by 
that number is the fill rate. Total cost includes all processing and 
includes both satisfied and unsatisfied requests. Unit cost is the total 
satisfied divided by the total cost. The marginal unit cost of referral is 
the additional nunber of requests satisfied by the referral divided ])y the 
additional cost incurred by the referral. 

With a uniform resource distribution, the time and strength * 
policies are identical since the nearest Center is always equal in strength 
to any other Center. The appropriate policy in this situation is to initial- 
ize a request at the nearest Center and, if not satisfied there, to refer it 
to the next nearest Center, etc. until the funding is exhausted. The unit 
cost and marginal unit cost of referral ai^e identical and independent of the 
number of referrals. Flxcept for the possibility of exceeding budget limita- 
tions, the only negative aspects of referral in a network with a uniform 
resource distribution is the possible increase in processing time due to 
increased demand on each Center. 

It is unlikely that any actual network would liave a uniform 
distribution of resources. We present it merely as a point of reference 
with which to compare other results. 

If the distribution of resources is skew and we employ a time 
allocation policy, then a request has a probability of (N - 1)/N of being 
initialized at a v/eak Center. If it is not satisfied at this initial weak 
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Strength 
Distributaon 


Allocation 
Policy 


0 


Number of 

1 


Vv "T o T* T* ' 1 1 o 
ivt. J. til. i.ci Jlci 

2 


3 


Total Satisfied 


Uniform 


Time 


64,000 


96,000 


112,000 


120,000 




Skew 


Time 


44,800 


74,240 


93,504 


106,048 




Skev7 


Strength 


64,000 


83,200 


96,640 


106,048 


Total Cost 


Uniform 


Time 


256,000 


384,000 


448,000 


480,000 




Skew 


Time 


217,600 


359,680 


451,968 


511,552 




Skew 


Strength 


?.56,000 


358,400 


430,080 


480,256 


Unit Cost 

■'J 


Uniform 


Time 


4.00 


4.00 


4.00 


4.00 




Skew 


Time 


4.86 


4.84 


4,tt3 


4.82 




Skew 


Strength 


4.00 


4. -31 


4.45 


4.53 


Marginal Unit Cost 


Uniform 


Time 


4.00 


4.00 


4.00 


4.00 




Skew 


Time 


4.86 


4.83 


4.79 


4.75 




Skew 


Strength 


4.00 


5.33 


5.33 


5.33 



Number of Requests Satisfied, Total Costs, and Unit Costs 
(Strong Fill Rate = 0.5, Weak Fill Rate = 0.3) 
Table I 
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Strength 
Distribution 


Allocation 
Policy 


Number of 
0 1 


Referr.^ls 
2 


3 




IJnif oi*n) 


Time 


89,600 


116,480 


124,544 


126,963 




blCGW 


Time 


32,000 


58,880 


81,344 


100,006 




Skew 


Strength 


89,600 


93,440 


96,896 


100,006 


LOZSLX Lose 


Uniform 


Time 


307,200 


399,360 


427,008 


435,302 




Skew 


Time 


192,000 


341,760 


455,808 


539,789 




OtvC-W 


D Lren^LU 


307,200 


353,280 


394 , 752 


432,077 


Unit Cost 


Uniform 


Time 


3.43 


3.43 


3.43 


3.43 




Skew 


Time 


6.00 


5.80 


5.60 


5.40 




Skew 


Strength 


3.43 


3.78 


4.07 


4.32 


Marginal Unit Cost 


Uniform 


Time 


3,43 


3,43 


3.43 


3.43 




Skew 


Time 


6.00 


5.57 


5.08 


4.50 




Skew 


Strength 


3,43 


12.00 


12.00 


12.00 



Number of Requests Satisfied, Total Costs, and Unit Costs 
(Strong Fill Rate =0.7, Weak Fill Rate =0.1) 

Table II 
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Center and is referred, there is a probability of (H - 2)/(N - 1) that it 

will be referred to anoCh.H" weak Center. Tf ;-e continue this emimor.Uion, 

we fim' that the probability of a request having been proceised by a strong 

Center increases with the number of referrals. Thus, the unit cost and 

marginal unit cost decrease with number oE referrals. The amount by which 

these costs decrease is directly related to the difference between the strong 

and x^eak fill rates. A large difference in those fill rates results in a large 

decrease while a small enough difference results in negligible decrease (I and II). v.- 

If we employ a strength allocation policy with a skew distribution 
of resources, referral always results in a request going to a weak Center 
since the strength policy, by definition, initiates a request at th<j Center 
strongest in the class of interest. Thus, unit cost and marginal unit cost 
increase v/ith the number of referrals. If all of the weak Centers in each 
class have equal weak fill rates, marginal unit cost will reach a constant 
after one referral. The increase in these costs is greatest when the 
difference between strong and weak fill rates is large (I and II). 

Thus, these two classes of policies have opposite effects on unit 
cost and marginal unit cost. The effects on total satisfied and total cost 
immediately agree with intuition. Comparing the time and strength policies 
for a skew resource distribution, we see that the strength policy results in 
more satisfied requests and initially the total cost is higher. However, as 
the number of referrals increases, the difference in total satisfied between 
strength and time policies decreases and the total cost eventually changes 
in favor of the strength policy. 



*Numerals in parentheses are references to tables. 
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If the four moasuros (lij,cusseu above vjo.re the only cunniderations, 
wc would choose the strength policy and use as immy referral r, as allowed with- 
in tota] cost, unit cost, ancVor marginal unit cojit constraint?:. However, we 
also V7ant to consider the average total lir.c or delay in satisfying a request. 
The nveriige delays for three values of our dispersion parameter D are sum- 
marized in Tables III and IV. 

We see that the average delay with the strength policy is initially 
much higher than with the time policy and that this difference increases 
markedly as the dispersion of the network increases. However, as the number 
of referrals increases the average delays with the two policies become more 
similar. In fact, if the difference between strong and weak fill rates is 
large enough, ths strength policy can result in an average delay less than 
that resulting with the time policy. (See Table IV for the skew resource 
distribution.) This effect is seen as the number of referrals increases and 
is due to the fact that the time policy results in requests staying in the 
network longer. 

Thus, we have seen the general effects of different allocation and 
routing policies on our measures of performance. How do we resolve the trade- 
offs and choose a specific policy? This is a large question which we do not 
intend to address in general in this report. However, we can consider a 
simplistic approach that illustrates how a policy might be chosen. 

Let us assume that our budget is constrained to $400,000 and that we 
are not concerned with unit costs or marginal unit costs. Further, assume 
that we have made a rather arbitrary value judgement that the strength policy 
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Network Strength Allocation Number of Referrals 

Dispersionj D Distribution Policy 0 12 3 



Uniform 


Time 


2.63 


3.57 


3.95 


4.23 




Time 


2.63 


3.75 


4.26 


4.72 


Skev/ 


Strength 


4.49 


4.46 


4.85 


5.02 



6 


Uniform 


Time 


2.63 


4.56 


5.21 


5.69 




Skew 


Time 


2.63 


4.93 


5.80 


6.58 




Ske\7 


Strength 


7.02 


7.20 


7.38 


7.55 



9 


Uniform 


Time 


2.63 


5.55 


6.49 


7.17 




Skew 


Time 


2.63 


6.12 


7.36 


8.45 




Skew 


Strength 


9.58 


9.75 


9.93 


10.10 



Average Total Time to Satisfy a Request 
(Strong Fill Rate -0.5, Weak Fill Rate =0.3) 
Table III 
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Network Strength Allocation Number of Referrals 

Dispersion, D Distribution Policy 0 12 3 

3 Uniform Time 2.63 3.28 3.47 3.56, 
Skew Time 2.63 3.94 4.56 5.23 
S^tcw" Strength 4.49 4.52 4.57 4.64 

6 Uniform Time 2.63 3.96 4.30 4.45 
Skew Time 2.63 5.31 6.37 7.47 
Skew Streng th 7.02 7.06 7.11 7.18 

9 Uniform Time 2.63 4.65 5.14 5.36 
Skew Time 2.63 6.69 8.19 9.74 
Skew Strength 9.58 9.61 9.66 9.73 

Average Total Time to Satisfy a Request 

(Strong Fill Rate =0.7, Weak Fill Rate =0.1) 
Table IV 
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will he used if the resulting per ctnt increase in average delay (over that 
\70 vould obtf.m with the time policy) docs not exceed one half o£ the result- 
ing percent: increase in total satisfied ♦ 

Considering the skew resource distribution x^ilh strong and X7eak 
fill rates of 0.5 and 0.3, respectively, ue find that the time policy with 
one referral and the strength policy with one referral satisfy our budget 
constraint. The strength policy results in 12% more satisfied requests (I) 
(than the time policy) and increased average delays of 24%, A6%, and 59% 
for D equals 3.0, 6.0, and 9.0, respectively (III). All of these per cent 
increases in average delay exceed one half the per cent increase in total 
satisfied and thus, the strength policy is rejected and the time policy 
accepted. 

Considering the skew resource distribution V7ith strong and weak 
fill rates of 0.7 and 0.1, respectively, we finO that the time policy with 
one referral and the strength policy with t\7o referrals satisfy the budget 
constraint. The strength policy results in 65% more satisfied requests (II) 
and, for D equal 3.0, this is more than twice the percent increase in average 
delay (IV). Thus, for D equal 3.0, the strength policy is preferred. However, 
for larger values of D , the per cent increase in average delay exceeds one 
half the per cent increase in requests satisfied and therefore, the time 
policy is preferred. 

Thus, we see that cost constraints, network dispersion, and the 
parameters of the resource distribution affect the choosing of an appropriate 
network operating policy. Even for somewhat similar networks, different 
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value judgements by the nanagor.s of e«ich network may result in very different 
policies being appropriate for caclj network. ILLINLT cannot make the value 
judsomcnts but it can provide the irfonnation necessary for the formulation 
of policy decisions consistent with the network manager's value judgements* 

Our next analysis of the hypothetical network considered the effects 
of having a union list or network Jjoldings such that all requests enter the 
Center level of the netv;ork with call number specified ♦ In such a situation, 
all requests are for owned resources and the only reason for a request not 
being satisfied is unavailability* Thus, we adjusted the probability of a 
resource being available to compensate for the difference in probability of 
a resource being o\med and the Center fill rate* As in our first analysis, 
we assumed that processing time was unaffected by the level of demand. 

Assuming a complete union list and that all requests are for 
material contained in this list, we find that the resulting performance 
measures significantly differ from those in Tables I through IV in only one 
component: cost. With a complete union list, no requests would ever be 
"searched" since a Center would know that any request sent to It is for a 
resource owned by the Center. Thus, the total cost is simply the cost of 
filling a request ($2.00) times the number of requests satisfied. The total 
costs resulting for the various^policies discuss<jd above are summarized in 
Table V* Note that cost savings can range up to almost $340,000 per year. 
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Strong/Weak Strength Allocation Number of Referrals 

Yill Rates Distribution Policy 0 1 2 3 ' 



0-5/0.3 Uniform Time 128,000 192,000 224,000 240,000 

Skew Time 89,600 148, A80 187,008 212,096 

Skew Strength 128>000 166,400 193,280 212,096 

0»7/0.1 Uniform Time 179>200 232>960 249,088 253,926 

Skew Time 64,000 117,760 162,688 200,012 

Skew Strength 179,200 186,880 193,792 200,012 

Total Costs With a Complete Union List 
Table V 



I'Jhile in actuality, one would probably not save as much as indicated 
by the figures in Table V, this analysis does point out that savings might 
justify the production of a union list of network holdings. As a by-product, 
each individual library in the network ^^?ould benefit from having a list of its 
own holdings for use by local patrons, schools, etc. 

A less impressive effect of the union list is the savings in time 
"searching" the request. As the network becomes more disperse, this difference 
becomes less significant • There is a potential here for savings in staff 
costs but xize have not analyzed the situation to determine the exact effects* 
Actually, these savings would affect the individual library but not the net- 
work since the network v^70uld no longer be paying for searching regardless of 
the individual library^s staffing decisions. 
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Oui- last analysis concerns the effects of queueinc in the network. 
The specific queueing models incorporated in ILLII^I-T are discussed in Appen- 
dix A- The basic idea of queueing is cis follows. If a process has a fixed 
average rate at which it can serve requests (termed the service rate with 
dimensions requests per unit time) then, as the rate at which requests arrive 
increases, longer waiting lines wilJ form and the total average time for a 
request to be processed (including x^aiting) will increase. To facilitate 
comparison between queueing and no queueing, we chose the service rates for^ 
the various queues in the network so that the time policy (with no referrals) 
in a network v;ith a uniform resource distribution and strong fill rate of 
0.7 would yield identical average processing times whether or not there was 
queueing. Then we increased the number of referrals which resulted in 
increased demand at each Center (more requests per unit time). Without 
commensurate increases in the rate at which requests could be serviced (by 
adding staff or new technology), the average delay in satisfying a request 
increased as shown in Table VI. The delays in this table include the time 
spent by requests waiting in queues, the time spent in actually being serviced 
and the time to deliver the requested resource. 

The increase in average delay with queueing is not a function of 
dispersion and thus, the per cent effect of queueing will decrease as 
dispersion increases. This will be true regardless of the queueing model 
we adopt. 

This analysis with queueing has served to illustrate how queueing 
can increase average delay and/or require increased staffing or new technology 



If we were to go back and consider again the tradeoff betvjcen total roquesLs 
satisfied and average delay, we \s'ould find that referral would result in 
increasing delay not only because of network dispersion but also because of 
the increased processing load on each Center. 

The queueing analysis could also be used to predict the additional 
staffing required to maintain a given level of service. VThile we have not 
yet added this option to ILLINET, it will be included in the future. Any 
analysis that does not consider queueing effects is likely to ignore one of 
the more important determinants of net^rork performance. 



Network ' Number of Referrals 



Queueing 


Dispersion, D 


0 


1 


2 


3 


No 


3 


2.63 


3.28 


3.47 


3.56 


Yes 


3 


2.63 


4.36 


5.28 


5.70 


No 


6 


2.63 


3.96 


4.30 


4.45 


Yes 


6 


2.63 


5.04 


6.11 


6.59 


No 


9 


2.63 


4.65 


5.14 


5.36 


Yes 


9 


2.63 


5.73 


6.95 


7.49 



Average Delays With and Without Queueing 
Table VI 



F. Conclusions 

We h^ve considered two fairly general classes of network operating 
policies; those that emphasize minimization of delay and those that emphasize 
maximization of fill rate. We have shown how network dispersion and the 
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distribution of resources affects the appropriateness of those two classes of 
policies. Combining cost constraints and value judgements concerning the 
tradeoff between delay and fill rate, we briefly considered choosing a specific 
netv7ork operating policy. 

We discussed network union lists, automated circulation, and 
computer-controlled networks. Considering ^the costs and benefits of each of 
these alternatives, a network union list might result in substantial savings 
in annual operating costs and thereby justify its production. Automated 
circulation systems V70uld have to be justified by the benefits to the 
individual library as the benefit to the network would be unlikely to justify 
the investment. The benefits of a computer-controlled network are numerous 
and this interesting alternative is discussed in more detail in a later report. 

When demand increases, waiting lines or queues form. Such queueing 
was shorn to substantially increase processing times throughout the network. 
This increase in processing time is one of the costs of referral. It either 
costs in service to the requestor or costs in increased staffing to maintain 
acceptable levels of service. 
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III, IN THE FUTURE 

Our current efforts are in three areas. First, we are continually 
trying to enhance the interactive features of ILLINET. One very important 
aspect of this effort is policy formulation. As noted earlier, for any 
reasonably complex network, there are thousands of possible netv/ork operating 
policies. To enable the user of ILLINET to consider a large number of policies, 
extensive on-line editing features have been developed that allow the user to 
construct one policy from another and thus, avoid having to start from 
scratch for each policy^ This saves considerable time, but further improvements 
are desirable and being explored. 

A second area of research concerns using simulation to test the 
queueing assumptions noted in our first report. The routing vector idea 
has eliminated the need for assuming a lack of knowledge of a request ^ s ^past 
routing. Currently, we are investigating the probability distributions of 
request interarrival times and service times. This should enable us to define 
the range of applicability of ILLINET. 

A third effort is aimed at investigating the impact of mini-computer 
circulation systems at various points in a network. Also, the possibility of 
a central switching computer for a whole network is being studied to determine 
its feasibility in terms of cost and impact on service. 

Our next project report will mainly consider analysis of the Illinois 
network in light of the data that is currently being collected. This report 
will discuss how data can be appropriately formatted and aggregated for the 
model as well as the analysis. 
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APPUNDIX A 



DERIVATION OF MODE]. EQUATIONS 

This version of ILLINET assumes a single-level distributed network. 
We will first consider the equations appropriate to such a nct\>?ork structure 
and then derive equations for the flow within each processing point. 

The network is Illustrated below. N processing points or nodes 
and M subject classifications are assumed. Class j requests enter the net\^ork 
at node i at an average rates of (requests/unit time). Associated with 
each request is a "routing vector" r^jj^. where k = l,2,...,n.j and n. . < N. 

hi 



'2i 

















/ 



/ 



/ 



/ 



3j 



The routing vector specifies the nodes that the request will successively 
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visit until it is either satisfied or roachec the last node specified by 
r.,, • To illustrate, since a type ij request is by dcfinitiioa initiated 

IJK 

at node i , r. = i . 

Defining p. ^ as the probability of satisfying a request in class 
j at node i and ^^jj^ ^^^^ probability of satisfying a type ij request at the 
k^^* node in its routing vector, we find*' 



where p^^ is assumed to be independent of a request's processing before enter- 
ing node i. The probability of a type ij request with routing vector r. 

ijk 

being satisfied is given by 

n. . 

And, the average probability of satisfying a request at the node where it 
entered the network is given by 




(2b) 



while the cumulative probability of satisfying a class j request is given by 



M / M 

P. = 2 ^. . P. . / 2 \ (2c) 
^ j=l 3=1 



*Subscripts are sometimes bracketed for clarity. However, the meaning 
does not change. For example p.. and p(ij) are equivalent. Also, for 

k-1 

k = 1, ^7^ ( ) A 1 and E ( ) ^ 0. 
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aud the overall probability of satisfying a request if, given by 

We should note here that the subscript i in equations (2) indicates the node 
at which the request entered the network and not necessarily the node at 
vhich it was satisfied. 

To determine the average time frc'a when the request enters the 
network until the requested document or information is delivered, define 
a)_ and U)^j as the average processing times for class j requests satisfied 
and not satisfied at node i, respectively. Also, define t. .as the 
average time to deliver the class j document or information when the request 



entered the network at node i. and was satisfied at node i^. t. . . includes 

^1^2^ 

^bnly delivery time and not processing time. With these definitions, we find 
that the average processing plus delivery time for a type ij request, 
satisfied at the k^^ node in its routing vector, i's given by 

Defining D^^ as the expected value of the total time from initiation of the 
request into the netxjork until delivery of the requested document or informa- 
tion. 

The expected total time to satisfy a request entering the network at node i 
is given by 
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M /M 

A ^''^ 



while the expected total time to satisfy a class j request is given by 



N /N 

°J = i'.i 'iJ °iJ \j ^'^^ 



and the expected total time to satisfy a request is given by 

N M /n M 

D = 2 2 X D / ^ EX (4d) 
i^l j^l / i=l j=l 

To determine t. , . , we need to know the source of requests entering the 
net;7ork at node i. Define \ , k = 1,2,...,L, as the rate at which 
class j requests from source k enter the network at node i . Further 
let t. be the average time to deliver a document or information from 
node i to source k. Then, 



t. . , = 2 X. t. , / X. , (5) 



Next, we want to determine the processing load on each node 
in the network. Each node must process not only but also requests 
referred to it from other nodes. Define A as the total class i 
processing load on node i. This is easily calculated recursively by 
intializing A_^^ = 0 for all i, j and then using 

k-1 

A(rj^jl,,j) = A(riji,,j) + ^JI^ [l-p(r. j^,j)] (6a) 
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for i = 1,2,..,,N; j = 1,2,..,,M ; k = l,2,.,,,n^j. The total processing 
load on node i is given by 



M 

A. = 2 A(i,j) (6b) 
j=i 



while the total class j processing load is given by 



N 



A 4 = 2 A(i,j) (6c) 
i=l 



and the total network processing load is given by 

N M 

A = S 2 A(i,j). (6d) 
i=l j=l 

Also of interest is the satisfied processing load. Defining 

A 

A.J as the average rate of type ij requests that are satisfied, 

^ij = Pij ^ij <7-> 

The average rate of satisfied requests entering the network at node i is 
given by 

M 

= 2 A (7b) 
j=l 

while the average rate of satisfied requests for class j requests is 
given by 

N 
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And the total average rate of satisfied requests is given by 

N M 
A= 2 2 A.. 

i=i j=i Oct) 

Defining X as the total rate of requests entering the network 
N M 

X = Z E X (8) 
i=l j=l 

we should note that A is usually much greater than X since requests are 
often processed at more than one node. A can be no greater than X since 
the network cannot satisfy any more requests than are input. 

Thus, X is the net\7ork input rate, A is the network output rate, 
and A is the network processing load a P is the probability that a request 
is satisfied while D is the average time required from initiation of the 
request into the network until the requester receives the desired document 
or information. 

Each processing node is, in itself, a network. The model 
adopted is shown below. We will term the processing nodes in this model 
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as subnodes. Subuode 1 represents in-processing of requests. Subnode 2 
represents the search of the catalog to cictcrmine if the materjal requested 
is o\mcd. Subnode 3 represents the obtaining of the material. Subnode 4 
represents the preparation and out-processing of the material. Subnode 5 
represents verification of the request in the sense of checking the 
correctness of the information supplied with the request, Subnode 6 
represents the out-processing of unsatisfied requests. The output of 
subnode 6 is A. which equals A. minus A. 

After a type ij request completes processing at subnode 1, it 
proceeds to subnode 3 with probability c^^ and to subnode 2 with probability 
1 " ^ij* ^here c^^ represents the probability that a request enters supplied 
with the trail number of the desired material. 

After processing at subnode 3, a type ij request proceeds to 

subnode 4 with probability a.^ and to subnode 6 with probability 1 - a 

3.J ij 

where a^^ represents the probability that the desired material is owned 
but not available. 

After processing at subnode 2, the request may proceed to subnode 
3 if the desired material is owned (with probability o.j). Or, it may 
proceed to subnode 6 if the desired material is not o^med (with 
probability 1 - o^_.) . Or, if the request is unverified (information not 
checked for correctness, with probability 1 - request might 

be forwarded to subnode 6 with probability f . Otherwise, the unverified 
request (with probability v<.j) proceeds to subnode 5 (with probability 

After processing at subnode 5, a successfully verified request 
(with probability s^^) is sent back to subnode 2. Otherwise, the request 
proceeds to subnode 6. 
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With these various probabilities defined, vje now want to 
determine the processing load on each of the subnodos. Let A be the 
average rate of class j requests entering the k subnode of node A 
moderate amount of bookkeeping yields 

^jl'^^j' (9a) 



\j2 = - fij)(l - v,j)] (1 - c..) A.^ , (9b) 

= ^^j °ij hi^' - fij)(l - Vij)]Cl - c.^]) A,.. (9c) 

= ^j^^ij - fij)(l - Vij)]Cl - c. .])A.^. (9d) 

V^^'-'ij^^^-^ij>^^-^ij>^j' (9e) 

^j6 = - "ijl^-ij hi^"- - fij>(l - Vij)])(l - c.^)A,j. (9f) 
Summing over classes yields 



M 



where A^^^> \^4> A^^^ equal , A^^, and A^ , respectively. 

Now we want to consider the processing time required to pass 

through node i. Define (O^j^ as the average time to be processed at the 
, th , ^ ^ 

K subnode of node i. From a queueing standpoint, (U^j^ is related to 
^i.k* ^iH' ignore this relationship until later in our 

discussion. Defining s^^ as the average delay experienced by a class j 
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request being satisfied at node i, we find that 



6 



ij ijk ijk 



(X =1 

ijl ^» 



^ij2 = °ij^j 2s.^<l - fijXl - Vij)]Cl - c.^])/of, 



a =1 
ij3 ^' 



a =1 
ij4 ^* 



^ij6 = 0' 



Similarly, define u^.^ as the average delay experienced by a class j 
request as it passes through node i unsatisfied. This quantity is given by 

6 
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where 



^ij2 = - + - ^j)Hv,j + 2s..(l - f..)(l - V..)] 

+ [(1 - s^.)(l - f..) + f ..][1 - v.^])(l - c..)/3, 
6,.3 = (1 - a..)(c.. + o..[v.. + s.jd - f ..)(! - v.j)](l - c.j])/3. 

By5= (-ijia-Oij)+Oija-a,.)] + Il-s^^]) 
(1 - f..)(l - v^.)(l - c^^)/6. 

3 = (l-ai^.)c^. + ([v,. +s.j(l-f.j)(l-v..)] 
[(1 - o^j) + o^jd - a.^.)] 

> 

V 1(1 - S^j)(l - f^.) + f - v^jDCl - C.j) 

All that remains in our derivation, is the determination of w , 

xk 

for use in equations 11 and 12. Each of the subnodcs in a processing node 
can be modeled as a queueing system as follows. 

Requests flow into the k^^ subnode of the i^^ node with an average 
rate of A<^^j^. These requests often arrive in batches. They queue up until 
a staff member (called the server takes all of the requests in the queue 
and services them as a batch. The server processes each request in the 
batch at an average rate of p^^^. Upon completion of servicing the batch, 
the server puts ^he requests in the queues of the appropriate succeeding 
subnodes and returns to his queue to pick up the next batch. 
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Requests experience delays in two ways. First, while waiting in 
the various queues, delay is experienced. Second, while in servicing, a 
request not only experiences the time required for its own servicing, but 
also must endure the time required to process every other member of the 
batch. Only then are all the requests passed on to appropriate succeeding 
subnodcs . 

The average total delay experienced to.j^ is related to the proba- 
bility distributions of which A..j^ and are parameters. If .... 
increases and co.j^ is to be maintained, must be increased either by 

increased staffing or productivity. If p cannot be increased, m , will 

XK. ik 

increase as A..j^ increases. Thus, an increased allocation of demand to a 
given network node results in increased service costs and/or increased 
processing delays. 

We would like an equation that relates co.. to A and u 

ik . i.k *^ik* 

Several approximations have been investigated but comparisons of these 
relationships with simulation results have caused us to reject these 
formulations and continue our search for an appropriate analytical expres- 
sion. The difficulty we are encountering is basically in finding a simple 
expression which does not require extensive analytical gymnastics every 
time A^,j^ is changed. 

The simulation results are, in themselves, interesting and of 
use. A FORTRAN queueing simulation was developed and tested by simulating 
queueing situations where the analytical solution was known. These tests 
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produced statistically acceptable comparisons and thus validated the 
simulation. Simulating the queueing situation described above and fitting 
a function to the results, we found that to^j^ can be approximately predicted 
using 

^ ^ • 1 (13) 

Ik (1 - p^j^) 

where 

^ik ~ ii^coming constant batch size. 
The simulation incorporated exponential interarrival and service times and 
constant incoming batch size. However, if we continue to use simulation, 
different interarrival and service time distributions may be employed as well 
as allowing for varying incoming batch size. 

Equation 13 can also be used to predict the \x^^ necessary to 
achieve a given w^j^. This would be of use for predicting the staffing 
and/or productivity increase necessary to meet anticipated changes in demand. 

Summarizing our queueing results, we feel that more effort is 
needed in this direction perhaps along the line of predicting oj^j^ for a 
general incoming batch size distribution and general service time distribu- 
tion. We plan to pursue these items and present them in later reports. 
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APPENDIX B 

SUMMARY OF ILLINET USER'S I-IANUAL 

This Appendix includes the first section of the four sections 
of the ILLINET User's Manual. This first section of the Manual sununarizes 
the use of the ILLINET model while the remaining three sections have de- 
tailed descriptions of model usage. Because of its length, we have not 
included the whole Manual. However, those readers interested in the whole 
Manual, will be furnished a copy upon their request. 
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ILLIN'ET UStR'S MANUAL 



1.0 In'Toduct ion 

1.1 How to Star? and End Execution of ILLINET 
1.? Interaction with ILLINET 

1.2.1 Procedures 

1. ?.? Sneci f icationr, 

1 .2.3 Ppta and Pol ir ies 
1.2. A Runnina the Model 

2.0 Data Fi les 

2.1 DSn/^T Procedure 

2.1.1 File Name Specification 
2. 1 .2 DcM.'ND File 

2.1. ' S.f^V^IM File 

2.1 .i SISPFIL File 

2.1 .5 PFLTIM Fi le 

2.1.6 C"?TS Fi le 

2.2 ET)^M Procedure 

2.2.1 File Name Specification 

2.2.2 D?ta Element Specification 

2.2. ^ Exarple of Editing a File 

2.3 SVn/^- Procedure 

2.3.1 File Name Specification 

2. h Rnn*T Procedure 

2.4.1 Fi7e Name Specification 

3.0 Policies 

3.1' tVKE Procedure 

3.1.1 Pol icyj=:abe1 Specification 

3.1.2 Allocation Specification 

3.1.3 P.outina Specification 

3.2 LIST Procedure 

3.3 DELETE Procedure 

3.3.1 Policy Number Specification 

3A C^PY Procedure 

3.4.1 Policy Number Specification 

3.5 RELBL Procedure 

3.5.1 Policy Number and Label Specification 

3.6 E^POl Procedure 

3.6.1 Allocation and Routing Specification 

3.6.2 Policy Number Specification 

3.6.3 Siihject Specification 
3.6./' Allocation Specification 
3.6.5 Routing Specification 

3.7 S^'POL Procedure 

3. P R^POL Procedure 

'npina the Model 

4.1 RWN Procedure 

4.1.1 Policy Number Specification 

4.1.2 T;=!hTe Name Specification 

4.2 RUNO Procedure 
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1 .0 IntroducL I on 

ILLT^*ET i*^ an Interactive conputer podcl for the desirn anc 
evaluation -^f hierarchical 1 1 brary/i nforra t i on netv/ork^>. The acronyr 
ILLIKET has tv/o neanincs* For this conputer proqrar, ILLIfvJ^T stands for 
Inter 1 lb*- ary Loan and Information Network HodeK Also, ILLH.TT is the 
name of the Illinois Lib-ary and Information Netv/ork under whose support 
this conputer rodel is being .developed* However, v/e v/ant to stress the 
fact that the ILLINET model has a general structure that is not specific 
to any particular network and can be used to design and evaluate a 
variety of network situations. The specific network of intere<;t is 
defined by Input data to the model as will be discussed In later 
<^ections of thi**. User's Manual. 

ILLINET nodels the following situation. l/e have a set of 
oe< nranhl ca 1 !y disperse resources and a set of geographically disperse 
denands. Co''->bInlnc these resources, denands, .and a communication 
protocol, v/f* have a network. The cornrrunicat ion protocol Is termed the 
retv/ork operatir.g policy. ILLINET predicts the effects of network 
operating policy on the following^ 

(1) probability of a reauest for a resource being satisfied 
(f i 11 rate) 

(2) average time from Initiation of a request until the 
requestor receives the desired resource (delay) 

(3) network operating costs 
ih) etwork processing load. 

To be consistent with t h e terminolo gy used ] n^he _1 1 1 i noi s net v/ork, 

the re-ource points in the network are called Centers. The points fror 
which derand eranates are called Systems. Demand is catenorized Into 
clas'^es which can represent subject areas, requestor status, etc. 
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This rianual is cornoosed of three main sections In additior 

to this I n' "or^uctcry <^ection. The first section deals v/ith Iho Input 
data for ILlIfTT that characterizes resources, demands, processino 
tines, etc# Also, in this section, ve discuss editing of data flles^ 
The second s'^cllon deals v/Ith tiie formulation and editing of network 
operatlnp policies. The final section deals with running tho netv/ork 
nodol and I nt^mr et I ng the results. 

1.1 How to Start and End ILLINET 

We assure the user is familiar with the log-in and log-off 

procedures of the specific computer he is accessing. This section of 

the manual will describe how the user begins Interacting with ILLINET 

and how to exit from ILLINET. 

Once the user has properly logged-in to his specific computer, he 
v/ill recelv<^ a signal that Indlcates*^e may access any files availahle 
to him. Again it is the u-.^r^s responsibility to be familiar with the 
spec'flc connuter he Is using. In the case of the DEC Systerr 10, the 
user Is notiflpcl by a period. This period Is sometimes referred to as 
the monitor level. Other computers signal the user In a similar v/ay 
although they ^ ay not use the period or specifically refer to the 
monitor If'vel. 

At the ronltor level, the user Is able to execute the ILLINET 
prooram. He enters RU ILLINET which In fact means run ILLIf^'ET. ILLIN'ET 
will Irrredlaf^ly respond with a The following Illustrates how the 

user begins execution of ILLINET and ILLINET^S first response: 
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Throu'-jhout this manual v/e v/i 11 present examples of Interaction vith 
ILLINET. The underlined segments indicate user input. All 
non-underlined response Is grnerated by ILLINET. (In the above example, 
the period is not Generated by ILLINET but by the specific corpputor 
facility bolnc] accessed by the user). 

The is a signal that ILLINET is v/aiting for Inforratiop to be 

ent'-red by the user. After receiving the the user pay enter the 

followinn options* 

(1) a "simple" carriage return 

(2) a "procedure" name followed by a carriage return. 

For nurposes of this manual, ve will define a "simple" carriage 
return a^. the user inputting only a carriage return. (For a given line 
of Input, a simple carriage return Is never preceded by other user 
Input). Entering a sinple carriage return at the '^f' level of ILLi:!CT 
will enr* execution of the program. The user will subsequently be 
returner^ to the monitor l^vel (signaled by a period In the car.e of the 
DEC System 10). At this point the user may log-off or access any other 
files available to him. The user should take note that all input must 
be terminated with a carriage return (sometimes referred to as the send 
key). 

The word "procedure" has a special meaning In ILLINET and will be 
defined in the following section. The various procedures available are 

summarized In section 1.2.1 and described in detail later in this 

manual. The user will have a better understanding of how to 
successfully utilize these procedures if he reads the entire manual 
before '"I'-ting at the terminal. 

o 49 
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1.? Int^^roctJon vith Il.LIf'FT 

To iPte'-nct with ILLIKTT, the ijr»or nunt provide "nroceduret;" and 
"snoc*f I cat I '^rr. A "procedure" Invokes a particular opor^tjon r>uch as 
cditino, I npuu/rutpnt ,et c. , while a "specification" indicates the data 
file or eler'^rts on v/hich the chosen operation is to be performed. 

Generally v/e can describe procedures as user Initiated. Inltiatlno 
a particular procedure will cause ILLINET to ask the user to speci-fy 
soro information or data. Those specifications are procedure dependent. 
In other word- , the user chooses the procedure while ILLINET asks for 
tho necessary snecl fi cat Ions to perform the desired procedure. 

The procodures described In this manual have the following general 
funct Ions • 

(1) access, ed:tlnp, and display of the input 
data files characterizing the netvork'^s demand 
level, fill rate, delivery time, and 

rrl inburserT>ent schedu 1 e. 

(2) creation, access, and editing of netv/ork operatinc 
policies which define the allocation and routing 

of reouests to various resource nodes in the netvyork. 

(3) operating upon specified data with the model 
to predict netv/ork perforrance. 

Th'^se ^upcti-^ns are described In the following four subsections. 
1*2.1 Procedures 

The purpose of procedures in ILLINET can briefly be described in 
terps of their operations- At the end of this subsection there is a 
list of procedure nanes and operations. 
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Procedu^ arc Input by the user after rocoivinr the frov 
ILLINET^ ILLJrET will only understand a procedure If It I'; entered at 
the leve'. During a 'esslon with ILLINET the user will probably 

utni:!e Por>l of the procedure^>» Since he can enter only ^ne rroce-^nre 
at a tlp'^, h'" ^ust direct bis Interaction with ILLJNET In such a vay 
that he returns to If^vel. The general strategy for escapinn fron a 

procedure and reaching the level Is to enter a simple carriage 

return In response to every specification asked for by ILLINET* (For 
the .definiti'^n of simple carriage return see section 1.1.) Upon 
returning to the level, the user can then select another procedure. 

Full explaratl n of all procedures are given In this manual. The 
specification requirements and the way in v/hlch one can exit froni a 
nrocedure e^o explained In the sections corresponding with the 
procedures . 

Any procedure name followed by an 'H' Indicates to ILLINET that. the 
user needs b'^lp. ILLINET responds by referring the user to the section 
or subsection of this manual which explains the procedure entered by the 
user. For exarnle, suppose the user wants to know the names of the data 
files which be can view at the terminal. Since this Is related to the 
DSDAT proceru'-o the user would enter 2 

<^ DSn/^TH 

SEE SECTION 2.1 DF THE USER^S MANUAL 

The followinn list briefly describes the procedures. For more detailed 
explanation ee the sections In this manual that correspond v/Itb the 
:>rocedur cs. 
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DATA ortf::'Ed procedures: 

PSD AT 

EDOAT 
SVDAT 



RDDAT 



Displays data fMe at the terminal 

or output all data files as hardcopy 
on the llneprlnter* 

Makes chanqes In elerrents of the 
data f I les# 

Stores data files (on disk) which 

have usually been edited. Editod 
versions of data fl les are thus 
available to the user during a later 
sessi on. 



Makes data files available (from 

disk) to the model. Used to restore 
the version of the data file as It 
existed before ah edited version. 

POLICY-n'>If:MTED procedures: 



MAKF 
LIST 

DFLrTE 
COPY 
RELPL 
EDPOL 

SVPOL 



RDPCL 



Creation of network policies. 

Listing at the ternlnal of 

existing policies by Identifying 
number and label. 

Deletes policies as specified by the 
user. 

Duplicates policies as specified by 
the user. 

Changes policy label as specified 
by the user. 

Changes In allocation or routing 

of the netv/nrk nollcles a'' specified 
by the user. 

Stores netv/ork oolicles (on disk) 
. created by the user. Access to 
previously created policies Is 

possible during a later session. 

« 

Makes available ( f rop' disk) to the 
user previously stored netv/ork 
pol I cl es. 
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nonPL-PnirfTED PROCEOUPES: 

Executes the mode) for specified 
policies, without the queueino 
option, 

^^^•^ Executes the model for -.pacified 

policies, with the queueincj option. 

1.2.? Specifications 

A specification is information that ILLINET requires to perform the 
ooeration indicated by the user's choice of a procedure. A single 
Question mark indicates that ILLINET is requesting a specification and 
waiting for user input. Specifications may be generally grouped as: 

(1 ) data f i le name 

(2) data file '^lement (numerical value) 

(3) center abbreviation 
(^) system abbreviation 

(5) class or subject abbreviation 

(6) table name 

(7) policy number 

(8) policy label 

(9) allocation vector for a policy 
(10) routing vector for a policy. 

In the rollowinn example ILLINET asks the user to specify a data file 



name 



FILE ? DEMAND 

This specification may have been requested after the user entered the 
nSDAT procec'ure. Detailed explanation of specification options is found 
in each section of this manual corresponding with a procedure. 

Typographical error":; and misspellings are checked by ILLINET. The 
user rs niven a list of abbreviations or names acceptable for the 
particular snoci f icat ion query, and asked for input again. For example: 



P<ic<: 10 

CE?'T^n ? CT5 

? ? CrNTEP.3: CT] ,CTr ,CT3 .CT^ 
Cri'TER ? 

The double nuoc-.tion mark Indicates ILLIKET does not understand tho last 
Input and a list of acceptable input options v/I 11 follow. The user is 
repeatedly a-kod for input tintll an acceptable specification is entered. 

Note that a" simple carriage return is an acceptable response and 
vlll cause ILLJMET to exit from the specification question. In some 
cases, this vi 11 result In return to the level or, in ether cases, 

to a more general specification level. 

1.2.3 Data and Pol id es 

Datf) and etwork policies are the quantitative Input to the model. 
Procedures and specifications are the communication tools which cause 
ope-ations t -> be performed upon the data and policies. 

Before the model Is '^xecuted, data files and network policies must 
be available. Data files are made available to the model automatically. 
The user Is not: required to define which data files are available for 
the model. However, If the user has utilized the EDDAT procedure at 
some time. It Is his responsibility to know which version of the data 
files the nodcl is using. See section 2.2 for an explanation of the 
EDDAT procedure. 

Network policies provided to the model must be Input by the user. 
Policies can he Input using the RDPCL procedure to access previously 
stored pollci'^o (from disk). Or, the HAKE procedure can be used to 
construct noy policies. Often , a new policy can be formed by edit I no 
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an -Id policy u-,inq the EDPCl procecure. For an explanation of netvorl- 
policies SCO <;oction 3.0. 

1.2. A Runnin'^ the Model 



While rrv-st of our previous discussion has focused on preparation 
and editinp of data files and policies, the heart of ILIUIEI is the 
network rrodol. Basically, the model is a distributed queueino network. 
It Is distribrted In the sense that any node can communicate a reouest 
to any other node. Quoueing comes into play when we choose the 
procedure that allows processing time at a node to be a function of the 
o'erand on that node (because higher demand results in longer waiting 
1 ines ). 

Running the model involves only the choice between two procedures. 
The RUN proced.ire is used to predict network performance in the absence 
of o.'-uelng. The user may select this procedure because he wants to 
compare performance with and without queueing to see the magnitude of 
the at.-eueinr effects. Or, the user may select the RUN procedure because 
he has insufficient data to consider queueing. The RUM procedure is 
discussed in section 4.1. 

The RUNQ procedure is used when one wants to consider queueing 
effects. It requires a little more data than the RUN procedure (see 
discussion of SRVTin file in section 2.1.3) but is a more realistic 
representation of a library/information network. The RUNQ procedure 
will eventually be programmed to predict the increased staf fine- 
necessary to keep processing time within acceptable limits in the face 
of increasef demand. However, this version of RUNQ is not yet 
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